home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 919 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  2. Subject: MiNT goes Unix
  3. Date: Mon, 17 Jan 94 15:20:39 CST
  4.  
  5.  
  6. I think we are preceding from the wrong end.  Instead of working on the
  7. file system structure and the compiler flags for using TOSFS file systems
  8. I think we need to look at the binaries themselves.
  9.  
  10. We aren't going to know what paths to put the binaries into until we
  11. know what binaries exist.  Then we can decide where to put them.  I'd say
  12. that the TOS Filesystem is not a problem.  Anyone running a Unix-like set-up
  13. is either going to run MINIXFS or somehting similar or is going to get
  14. some sort of fix for the TOSFS, someone mentioned a GEMDOS FS that called
  15. Unix2Dos.  If you want the library to support specific TOS FS naming
  16. then use Dpathconf to find out the limits of the filesystem at run-time and
  17. then decide if the filename needs mangling.
  18.  
  19. My enviroment is gone crazy.  We need a better way of configuring.  Perhaps
  20. a configuration directory?  So that an ENV var points to a directory where
  21. config files are kept.  A program would then load in its config file from
  22. the directory instead of having a cluttered enviroment.  For speed reasons,
  23. a Binary configuration utility would be best - to modify the executables
  24. to change paths and defaults (perhaps a TOSFS switch if Dpathconf is too
  25. difficult or inefficient to determine file name mangling conventions).
  26.  
  27. I'm in support of rewriting GEM.  GEM is using up 90% of my CPU time and
  28. that is when my mouse doesn't move and the keyboard doesn't move.  I wrote
  29. my own little mouse tracking facility that used Fselect with /dev/mouse
  30. and /dev/console to track the mouse and work out double-click events and
  31. such.  Not only did it work, and used NO CPU time when I didn't move the 
  32. mouse or type, but I couldn't make it use more than about 5% and I tried
  33. real hard!  If ATARI isn't willing to rewrite GEM, perhaps we should?
  34. How hard could it be to rewrite the AES - perhaps structure it like
  35. NeXT Step (or add more direct X emulation although I think X is too inefficient
  36. for use on an ATARI).  You can add wrapper functions to emulate the older
  37. AES calls or something.  It would be a difficult undertaking, but the
  38. machine is going to be hindered badly unless you remove the OS polling.
  39.  
  40. I think we should also work on getting a non-blocking fork() and non-blocking
  41. IO too.   If PowerDos can do it, then it can be done.  DMA disk IO doesn't
  42. have to lock up the whole machine does it?
  43.  
  44. To start, lets get a list of binaries that are available for MiNT.  We
  45. can then decide where these binaries should go in a Unix hierarchy, 
  46. deciding between whatever current ... standard? .. best fits what we've
  47. got and then we can also decide what sorts of binary configuration can be
  48. added to those programs.
  49.  
  50. Its a place to start.  I'm always in favor of a place to start over
  51. theory.
  52.  
  53.  
  54.